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ABSTRACT 



A network match making system and method is used to 
match users of a multi-user networked application. Each 
user is associated with a client computer connected to the 
network. Clients are selected based on attributes of their 
users, the clients, servers, and/or communication links. The 
network match maker works with three different forms of 
network applications: peer-to-peer, multiple clients to a 
single server, and multiple clients to multiple servers. In one 
late server binding method, a set of computer objects is 
created. The set of computer objects has a plurality of client 
instances of client computer programs together with a server 
instance of a server computer program selected from a set of 
server instances. A match maker receives from a first client 
instance a first request to be joined into the set of computer 
objects. The first request has first client attributes associated 
with the first client instance. The match maker selects a first 
server subset of the set of server instances in response to the 
first request based on the first client attributes and creates the 
set of computer objects consisting of the first client instance. 
The match maker augments the set of computer objects with 
a second client instance of a client computer program. In 
particular, the match maker receives from the second client 
instance a second request to be joined into the set of 
computer objects. The second request has second client 
attributes associated with the second client instance. The 
match maker removes a second server subset from the first 
server subset in response to the second request based on the 
second client attributes and adds the second client instance 
to the set of computer objects. Finally, a member of the 
second server subset is added to the set of computer objects 
based on attributes associated with each member of the set 
of computer objects. 

18 Claims, 9 Drawing Sheets 
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OBJECT-ORIENTED METHOD FOR The present invention presents a network match making 

MATCHING CLIENTS TOGETHER WITH system that solves the above described problems in the prior 

SERVERS ACCORDING TO ATTRIBUTES art and provides an automated means for users to be matched 

INCLUDED IN JOIN REQUEST with one another for a networked application. The network 

DcnnDtrNTrM? ™ ___ 5 match maker not only takes into account the users prefer- 

™ nin ciVSr a t a om t nwr^ ences and altrib *es, bui the attributes of the client computer, 

PROVISIONAL APPLICATION me application, any optional servers needed by the applica- 

This patent application claims the benefit of U.S. Provi- tion and the properties of the communications links between 

sional application Ser. No. 60/013,812, filed on Mar. 21, the clients and the clients and any optional servers. 

1996, now abandoned. io These and other features and advantages of the present 

BACKGROUND OF THE INVENTION invention will become apparent from the following detailed 

description of the invention and accompanying drawings. 

Computer networks are widely used to connect multiple 

computer systems together for communicating and sharing BRIEF DESCRIPTION OF THE DRAWINGS 

information. Computer networks can also be used to imple- 15 . . _ , , . . . . 

_ * n- r i* *u * ii i** i * rlu. I is a now chart showing the interaction between a 

ment multi-user applications that allow multiple users to n 4 , , , . & , , ^ lv, ^ lJ a 

„l„ 0 ■ t . *S n n M , , ^ L nrst client and a match maker m accordance with the present 

snare in the operation or a computer program. Common invention 

examples are video and teleconferencing applications, 

online multiplayer games which allow multiple users to play FIG. 2 is a flow chart showing the interaction between a 

a game with one another and online chat environments. A 20 second client and a match maker in accordance with the 

problem common to all such multi-user network applica- present invention. 

tions is providing an efficient way to bring together groups FIG. 3 is a flow chart showing the interaction between 

of users to join in the running of a multi-user application. clients and the match maker of FIGS. 1 and 2 in accordance 

Today, the known solutions deal only with the users require- with the present invention. 

ments such as which other people they wish to be matched 25 FIG. 4 is a flow chart showing measurement of commu- 

with. These solutions provide little more than manual meth- nication attributes in accordance with the present invention, 

ods for the users to select the other users that they wish to FIG> 5 is a flow chart showing the steps in matching in 

be matched with. This is workable only when there are accordance with the present invention, 

reasonable numbers of users in the pool of all users. It „ T ~ , , _ , . . , , 

u i ui u *u i i »» _ A rlu. o and 7 are now charts showing termination methods 

becomes unworkable when there are large numbers of users 30 . , . , , . & lw " iniolJU " 

a u *u r ** u ■ i • * c * m accordance with the present invention, 

and when the application has special requirements for net- * 

work performance or capabilities of the client and/or server FIG - 8 is a flow chart showing the interaction of clients, 

computer systems used to implement the application. servers and a match maker in accordance with the present 



Networked applications for multiple clients exist in three 



invention. 



forms. Peer-to-peer applications are executed by multiple 35 FIGS - 9-10 are flow cnarts showing the use of commu- 

client computers with no server or servers required. All nication attributes in accordance with the present invention, 

communication traffic during the execution of the applica- FIG. 11 is a flow chart showing the matching operation of 

tion is directed between the clients. Other multiple client the match maker in FIG. 8. 
networked applications use a single server system. The 

server may execute some portion of the application that is to 40 DETAILED DESCRIPTION OF THE 

be shared by all of the clients while the remainder of the INVENTION 

application is executed on the clients. The server can also act xh e preS ent invention involves a network match making 

as a communications collection point. Some or all of the process running on a server system on a network that is used 

communication traffic is between each of the clients and the b y clients to be matched into matched sets of clients for a 

server. The clients may additionally communicate with one 45 multi . user application. When the networked application 

another as needed. Finally, multiple servers may be used in operates in a networked system with multiple servers that 

a multiple client application. Similar to the case of a single may be used by the application, the network match maker 

server, a portion of the application may be executed on the a is 0 ma tches a server to the matched set of clients. A key 

servers. The multiple servers can also provide communica- i dea benind the pre sent invention is that clients and the 

tions collection points for the clients. 50 seryer afe matched nQt Qnly 0Q the basig of uger attributeS) 

SUMMARY OF THE INVENTION °ut on basis of client, server and application 

r t . ^ . t , . . 4 attributes and on network performance characteristics 

In the present uivenUon a network match malung system mcludi bandwidth> lal [ nd ket loss 

is used to create matched sets of users of a multi-user 

networked application. Each user is associated with a client 55 tributes 

computer connected to a network. Also on the network is a ^ network match maker matches clients and a server 

server computer which executes a software process that is int0 matched sets by comparing the attributes of the user, the 

the network match maker. In some implementations there client > the ^wer and the properties of the network links 

are one or more additional servers that are also used for between them to the requirements of the application, 

supporting the networked application. The clients are 60 Client and user attributes 

selected into matched sets based on attributes of their users, The user attributes include the obvious characteristics of 

the clients, application class and instance, the attributes of the user that are relevant to the networked application. Some 

the servers and the properties of the client-to-client and examples include things such as skill level, age, people the 

client-to-server communications links. The network match user doesn't want to be matched with. For the sake of a 

maker works with three forms of network application imple- 65 clearer discussion, the user and client attributes will be 

mentation: peer-to-peer, multiple clients to a single server lumped into one group, and is referred to as "client 

and multiple clients to multiple servers. attributes." Client attributes describe the capabilities of the 
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client computer system. The performance of the client 
computer, the type and performance of its network link and 
the types and versions of the networked applications that are 
installed on it are all reasonable examples of client 
attributes. 5 
Application attributes 

The application attributes are the requirements of the 
networked application. Examples of these requirements 
include the type and performance of the client, the type and 
performance or any necessary server and the required prop- 10 
erties of network links between the clients and between the 
clients and the server. Application attributes come in two 
forms, class and instance. The class attributes of an appli- 
cation apply to any instance of the application. The net- 
worked match maker operates in an environment where 15 
there will be multiple instances of each application. When an 
instance of an application is created, it inherits the class 
attributes while additional instance attributes may also be 
applied. These instance attributes may simply override some 
of the class attributes inherited by the instance, while others 20 
may be specific only to application instances. 

Server attributes 

Example of static server attributes include the type and 
performance of the server system, types and versions of any 
networked application software that is installed on the 
server. Dynamic attributes include the current load on the 
server. Considering the current load on the server when 
assigning application instances to a server is a way to effect 
dynamic load balancing on the servers in a multiple server 
system. 

Communications attributes 

Communications attributes are the properties of the net- 
work link between two computer systems. These will 
include the links between clients and links between clients 35 
and a server. The properties of network links will include the 
available bandwidth, the latency and the packet loss rate. 
Many networked applications will have certain minimum 
requirements for bandwidth and maximum requirements for 
latency. There are other metrics of communication perfor- 40 
mance that may be valuable measures of the properties of a 
communications link between two computer systems that 
also can be used. 

Types of Matches 

The network match maker forms matched sets of users by 45 
either automatically matching users into matched sets or 
allowing users to create match offers that other users may 
browse and then choose to join until full matched sets are 
completed. In both of these cases, the match maker will 
choose a server for the matched set if multiple servers are 50 
available and the networked application requires it. Auto- 
matic matching is a simple variant of user created match 
offers, so the user created match offer case is discussed first. 

In both of these types of matches, there is the concept of 
a moderator. The moderator is the agent that chooses the 55 
instance attributes of a match offer. When the match offer is 
created, it inherits the class attributes of the application. The 
moderator may then modify the attributes to create the 
match offer instance attributes. When the application is 
launched for a match offer, it does so using the instance 60 
attributes of the match offer. In user created match offers, the 
most simple case is that the user that created the offer is the 
moderator. In automatic matches, the match maker itself is 
the moderator. Other possibilities exist. It is possible for 
some or all of the users in a match offer to share powers of 65 
the moderator. They may be able to override each others 
attribute choices so that the last setting of the attributes wins, 



or there may be a voting scheme between the users sharing 
moderator powers. It is also possible to imagine a mixture of 
match maker and user moderator powers. Some of the 
instance attributes might be set by the match maker and 
others by one or more users that join the match offer. 
User Created Match Offers 

Users may create their own specific offers to other users 
to match with. These are called match offers. To create a 
match offer, the user will choose one application for which 
to create a match offer. The offer will inherit the class 
attributes of the application, but the user may add additional 
instance attributes for their specific match offer. The user 
that created the original match offer will be considered the 
moderator of that offer and will be the only one that is able 
to select the instance attributes of the match offer. Other 
users will browse these match offers, examine their 
attributes, select an offer that they find acceptable and 
attempt to join that offer. The match maker will compare the 
client attributes and the communications attributes of any 
relevant communication links to the required instance 
attributes. If they do not match the required attributes of the 
match offer, the match maker will prevent the user from 
joining the match offer. If they do match, the new client will 
join the offer and will be added to the matched set of clients 
associated with the offer. As clients attempt to join the match 
offer, the match maker will also compare their attributes with 
those of the other clients to make sure that the user attributes 
are compatible before a client is allowed to join the match 
offer. Once enough clients have joined the match offer, the 
moderator can select to launch the application. 

How the network match maker determines how the prop- 
erties of any relevant communications links affect which 
clients can join a match offer depends on the architecture of 
the networked application and is described in the following 
sections. 

Peer-to-peer 

When the client requests to join a match offer, the network 
match maker will ask the new client to measure the prop- 
erties of the communications links between the new client 
and all of the existing clients that already are members of the 
match offer. The properties of the communications links 
between the new client and the existing clients that are 
members of the match offer will be returned to the match 
maker in a vector of network properties. These properties 
will be compared to the requirements of the instance 
attributes for the match offer. The application will have its 
own class attributes for communications properties of the 
network links between the peers needed to run the applica- 
tion. The creator of the match offer may override these 
attributes to create instance attributes for the properties of 
the communications links between the peers. If the client 
attributes and the attributes of the communication links 
match the requirements of the application instance, the new 
client will be joined into the match offer. 

Multiple clients to a single server 

In this case, the server is assumed to have all of the 
necessary properties to host the necessary portions of the 
application. As with the peer-to-peer case when a client 
requests to join a match offer the network match maker will 
ask the new client to measure the properties of the commu- 
nications links between the new client and all of the existing 
clients that already are members of the match offer. These 
properties will be returned to the match maker as a vector of 
communications properties which will be compared to the 
requirements of the application instance attributes for com- 
munications properties of client-to^client links. In this case 
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the network match maker will also ask the new client to prevent some clients from joining a match offer that they 

measure the properties of the communications link between could have joined if a different server had been selected, 

the new client and the single server. The properties of this This is clearly the case if network latency is one of the 

link are also matched to the instance attributes for commu- important properties of a network link. With early binding, 

nications properties of the client-to-server link. If all 5 a qualified server with the lowest communications latency to 

matches properly, the new client is allowed to join the match the client creating the match offer will be chosen. This 

offer. In many multi-user networked applications that use a latency may be far lower than the latency required by the 

single server all client-to-client communications will be match offer. The latency requirement of the match offer 

through the server, so there will be no direct client-to-client creates a virtual "sphere" around the chosen server. Clients 

communications. In these cases, only the properties of the JQ that match the attributes of the match offer that are within the 

communications links from the clients to the server will be latency sphere centered around the chosen server will be 

relevant. able to join the match offer. Depending on the location in 

Multiple clients to multiple servers latency "space" of other qualified servers and other clients, 

With multiple server systems, the situation becomes more another server may be a better choice that will not only allow 

complex. Not only must the system consider the properties 15 me creator of the match offer, but more clients than the 

of the communications links between the clients and the original server choice. 

multiple servers, but additionally the attributes of the server Server late binding eliminates this issue, but is more 

systems. Not only must the network match maker match the complex. With server late binding the network match maker 

clients into matched sets, it also must determine which of maintains a pruned list of qualified servers for a match offer, 

multiple server systems is to be associated with each 2 o ^ ne cue nts J om tne match offer in the usual way. The 

matched set of clients. In the discussion here, it is assumed attributes of the new client are first compared to those of the 

that the match maker will ultimately choose a single server match offer. If they match, the properties of the network 

to be matched with each matched set of clients associated links are compared. The match maker compares the prop- 

with a match offer. The approach outlined here can be easily erties of the network links between the new client and the 

generalized to support applications that required multiple 2 s member clients of the match offer to the instance attributes 

servers to be used when running a multi-user application. of the match offer. If they match, the properties of the 

However, there are two server selection policies that the network links between the client and the pruned list of 

network match maker can use to select a specific server for servers is compared to the instance attributes of the match 

a match offer called early server binding and late server offer. If one or more of the communications links between 

binding. 30 ^ e new cuent an d tne pruned list of servers meet the 

When a client asks to join a match offer for a particular requirements of the match offer the cuent is allowed to join 

application, the network match maker asks the client to it- The network match maker then prunes the list of servers 

measure the properties of the communications links between associated with the match offer to eliminate any for which 

itself, all of the other clients that are members of the matched foe properties of the communications link from the new 

set associated with the match offer and all of the server 35 client to the server did not meet the instance attributes of the 

systems that are available for that application. The servers match offer. This will guarantee that the existing clients that 

available for that application are a subset of all of the servers are members of the match offer will continue to meet the 

based on the attributes of the servers and the attributes for requirements of the match offer. When the moderator finally 

server requirements for the match offer instance. When a chooses to launch the game, there may be more than one 

client creates a match offer they may specify instance 40 server in the pruned server list. The network match maker 

attributes for the application that override or add to the w iU select a final server using a selection criteria that it 

application class attributes. This may further limit the subset chooses. Typically this selection criteria will choose the 

of server systems that can support the application. When a server with the best overall communications properties to all 

new client requests to join the match offer, the network of the client that are members of the match offer. In many 

match maker will compare the client attributes to the 45 network applications, there will be no direct communica- 

required attributes of the match offer. If they match, the tions between the clients. There will only be communica- 

network match maker will then compare the properties of tions between the clients and a server. In this case there will 

the relevant communications links to the requirements of the De no oeed t0 measure properties of the communications 

specific match offer. links between the clients and so this will not be part of the 

With early server binding, the network match maker 50 match making process, 

chooses the server from the qualified subset of servers using Automatic Matches 

only the properties of the communications links between the Automatic matches are very similar to user created match 

creator of the match offer and the qualified servers. If offers except that the users ask the match maker to create 

multiple servers have communications links to the creator of automatic match offers to match them with. A user specifies 

the match offer that meet the requirements of the match 55 an application to run and requests an automatic match. The 

offer, the network match maker will choose one based on network match maker looks at the users requesting an 

some defined criteria. A reasonable criterion would be the automatic match of the same application and attempts to 

best performance, but other criteria would be possible. As a organize them into matched sets. The match maker creates 

new client attempts to join the match offer, the match maker automatic match offers to which it matches the clients. As 

compares the client attributes, the properties of the commu- 60 part of creating an automatic match, the user may be given 

nications links between the new client and the existing foe ability to specify modifications to the attributes of the 

members of the match offer and from the new client to the automatic match offer instance of an application. As an 

selected server. If all of these attributes and communications example a user might ask for an automatic match for a game 

properties meet the requirements of the match offer, the with only expert players. 

client is allowed to join. While early server binding is the 65 When a client requests an automatic match, match maker 

simplest server selection policy, it may not always result in will compare the client attributes and communications prop- 

the best server selection for all of the clients and it may erties of the requester as applicable to the attributes of the 
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existing automatic match offers. If the client attributes and 
applicable communications properties of the client match an 
automatic match offer, the client will be entered into the 
matched set of clients associated with the match offer. If the 
attributes of a client and applicable communication proper- 
ties do not match the instance attributes of the automatic 
match offer, the match maker will move on to the next 
automatic match offer. This continues until the client has 
been matched to an automatic match offer, or there are no 
more automatic match offers. If the new client has failed to 
match any of the automatic match offers, the network match 
maker creates a new automatic match offer and joins the new 
client with it. When a particular automatic match offer 
contains enough clients as required by the attributes, the 
match maker causes an instance of the application to be 
launched. The network match maker will also support a 
reasonable time-out period for the launching of automatic 
match offers. 

The particular cases of peer-to-peer, multiple clients to 
single server and multiple clients to multiple servers are all 
handled in this frame work as they would with user created 
match offers. A final detail of automatic match offers is that 
users that are manually browsing match offers will also see 
and be able to join the automatic match offers. 

Examples of Communications Attributes 

The most important communications attributes are 
bandwidth, latency and packet loss rate. Other attributes of 
communications networks may be important in some 
applications, but these are the most broadly important 
attributes. Below are examples of how these attributes 
would be used by the match maker for matching clients and 
servers to a match offer. For the purposes of these examples, 
the discussion here relates only to how the communications 
attributes are used in the match making process. The other 
client and server attributes will be ignored. 

Bandwidth is the data rate that can be supported by a 
particular network link. Networked applications will have 
requirements for the data rates that they need to send 
between clients or between clients and a server. Consider as 
an example an application that be operated with or without 
speech communications between the clients. When used 
with digital speech, the speech data consumes a significant 
amount of data bandwidth. Further consider that the appli- 
cation is a peer-to-peer application with no need for a server. 
In this example, a user creates a match offer for this 
application and sets an instance attribute for this match offer 
to enable speech communications. When a new client 
requests to join the match offer, the match maker will ask the 
new client to measure the bandwidth between the new client 
and all of the clients that are already members of the match 
offer. If the bandwidth between the new client and any one 
of the existing members of the match offer is too low to 
support the bandwidth requirements of the application when 
speech is enabled, the match maker will see that the client 
attributes for communications bandwidth to one of the 
existing clients does not match the instance attributes of the 
match offer for client-to-client communication bandwidth. 
The new client will therefore be prevented from joining the 
match offer. The same client may be allowed to join a match 
offer for the same application when the match offer instance 
specifies that client-to-client speech is not enabled. This will 
be true if the match offer instance attributes for client-to- 
client bandwidth are equal to or lower to the bandwidth from 
the new client to each of the existing client members of the 
match offer. 

Latency is another important communications attribute. 
Latency is the time for a communications data to travel over 
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a network link from one system to another. Many interactive 
applications will have strict requirements for communica- 
tions latency that if not met will prevent the application from 
operating properly. Total latency on a communications link 

5 will be the sum of many factors including the propagation 
time of signals over long distances. The other factors can 
generally be minimized or reduced, but propagation delays 
are set by physical laws. Imagine a highly interactive game 
that is played between multiple clients through a server. 

10 Each client in a game instance sends and receives its 
communications data to the other clients through the server. 
In this example, also consider that the pool of potential 
clients to play the game are spread over a wide geographic 
area and that there are multiple servers also spread through 

15 the same area. The example game has strict latency require- 
ments for the communications delay between the clients and 
a server used for a game instance. If the latency between a 
client and the server exceed this, the quality of the game play 
for the client or all of the clients in the game instance may 

20 be unacceptable. In this example, the match maker must not 
only match clients together into matched sets, but it also 
must match each matched set of clients to a specific server. 
As described earlier there are two methods of matching the 
server to a group of clients: early server binding and later 

25 server binding. With early server binding, the match maker 
will choose the server that has the lowest measured latency 
to the first client in the match offer. As each new client 
attempts to join the match offer, the match maker will ask the 
client to measure its latency to the server that has been 

30 selected for the match offer. If the measured latency meets 
the requirement of the match offer instance for latency, the 
new client will be allowed to join. The end result is that all 
of the clients that join the match offer will meet the require- 
ments for latency of the match offer instance. With server 

35 late binding, when the match offer is initially created, the 
match maker will create a list of all of the servers that match 
all of the instance attributes of the match offer. As clients 
join the match offer, the match maker will ask the clients to 
measure their latency to each of the servers in the list. The 

40 new client will provide this vector of measured latencies to 
the match maker. Each latency in the vector will be com- 
pared to the latency attribute requirements of the match 
offer. If one or more the latency vector elements meet the 
latency requirements of the match offer, the new client will 

45 be allowed to join it. The match maker will then prune from 
the server list associated with the match offer any servers 
whose corresponding latency vector elements for the new 
client did not meet the requirements of the match offer. Once 
all of the desired clients have joined the match offer, there 

50 may be more than one server that are in the pruned list. The 
match maker will then use some criteria to select a single 
server. One criteria would be to choose the server that 
minimized the average latency between that server and all of 
the clients. Another criteria would be to minimize the 

55 latency differences between each of the clients and the 
server. 

In a well managed network, most of the latency between 
two points in the network will come from the network 
propagation time. In both the early and late server binding 

60 cases, this will mean that the clients will tend to be matched 
to servers that are located near to them in the network. If the 
network tends to minimize the lengths of the network 
connections, this will result in clients being matched to 
servers in their geographical vicinity. 

65 Packet loss rate, is the rate at which data is lost during 
transmission in a network. Most networks transmit data in 
discrete units called packets or frames. Some networking 
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protocols such as UDP do not provide guaranteed data compared to the required attributes of the application. The 

delivery so it is up to the application to either be tolerant of properties of the appropriate network links are measured and 

transmission loss or provide a means to retransmit the data. matched to the required network attributes of the applica- 

Other networking protocols such as TCP/IP do provide tion. If all matches, the new client is allowed to join the 

guaranteed delivery. However, when a packet is lost this 5 running application. At a later time the client may leave the 

must be signaled to the sender and the transmission retried. application. This situation is the same as clients joining a 

Unfortunately, this takes time and introduces a large delay match offer with early server binding, 
before the lost packet can be recovered. In some 

applications, this delay causes more problems than the loss DESCRIPTION OF AN EMBODIMENT OF THE 

of the data. Therefore, many interactive applications will 10 INVENTION 

have requirements for maximum tolerated packet loss rates, AU . . tU . , . F# . . . 

™ . M . . . , „ , \ t , ,• , Although the above description of the present invention is 

This then becomes an important attribute of a network link . r *u • *• « j c 

t . . . .u > u i ♦ -j entirely enabling of the invention generally and of this 

that an application may want the match maker to consider as . ■ i . J- -i in j 

. p • u- r . . .u«? j * embodiment m particular to a practitioner ordinarily skilled 

part of matching clients to a match offer and a server to . -j * ■ 1 1 j . j- 

.uj.<;?.tu'»*u. m.l i . . in the arts, as an aid to more quickly understanding the 

matched set of clients. This attribute will be used in a similar 15 . .* . - , . . J . . f ,. 

, n trt „ ot „_ , •«t,:K„f«, invention it is useful to consider in some detail an embodi- 

lasnion to the other network attributes. . . . . . . .. . „ . . _ 4 , 

ment that contams only a relatively small subset of the 

Generalizations to the invention invention and which is therefore relatively simple to 

The previous discussion of client-server applications only describe and also is relatively quick and easy to understand. 

considers the cases where this is only a single server or the ^ presenl embodiment relates to matchmaking for Peer 

match maker chooses a single server from multiple servers to Peer games that fe t0 say games that play wixhoui the ^ 

to match to a match offer. It is also possible in the case where of aay Servers even though the matchmaker is itself imple- 

there are multiple servers that the application may require mented as at i east one Server> ^ Det work that this par- 

multiple servers. Consider an application that has two forms ticular embodiment uses is the well known Internet which 

of data that it transmits through the network. As an example uses the also well known i nte met Protocols (such as TCP/IP 

consider an interactive game that supports speech commu- and UDP/I p). Moreover, for simplicity since the present 

mcations between players. It will transmit game information embodiment is described only by way of illustration of the 

and user speech data that it separates into two separate data above described invention, only a relatively few of the 

streams that flow between the clients and two different possible alternatives are incorporated into this particular 

servers. One server will handle the game data while the other embodiment. 

the speech data, This allows the server that handles the 30 t , . . A , , 

K , t , . , ... ..... The term computer program is commonly abbreviated to 

speech data to be equipped with special capabilities specific a * u i • j 

, 5 j . • * *■ ** * »u i- * program. A matchmaker server program is used, an execut- 

to processing the speech data prior to routing it to the clients f . . , . , , A 

t u * • • -* m S instance or this program (abbreviated to MM) resides on 

tnat are to receive it. . m *■ » 

a server computer. I ne concepts ol server computers and 

With this arrangement, the application will require two 35 executing instances of programs arc well known in the 

servers, each with unique attributes. Since the game data and computing arts. Each computer user (abbreviated to user in 

speech data will have different bandwidth, latency and mis embodiment) launches an instance of a client computer 

packet loss requirements, the application will have separate prog ram on his computer which computer is then a client 

requirements for each of the two data streams. This will computer for the time being. 

mean that there will be two sets of application attributes for An r>„c„„- tn ci^ i ■ „♦ n ♦ pi*. 

- , i i- t t_ L i- j t_ 40 Referring to FIG. 1, in step 11, an instance of a client 

properties of the network links between the clients and the m (cu) ^ a f tQ ^ MM ^ ^ of 

servers. During the match making process in this example m exchanges by means of Internet communications to 

the match maker will ask a client requesting to ioin a match A . ■ m • .u ^ . ■ j 

~ . . * . * \ <• * send requests is well known in the data communications and 

offer to measure the properties of the network links from the /• . r™ . , (U UM , 

,. #4 u i t- .i. i- i_ n j computing arts. The request asks the MM to create a game 

client to each of the two servers. For the client to be allowed 1C & ,f. ♦• i j ♦» u . • 

... . „ , , , , . 45 offer and the request includes attributes of the various game 

to join the match offer, both sets of network properties must „ t u ? , . #u ... 

J , , ' ., „ , ; f £. _ and match preferences chosen by the user together with 

mateh the instance attributes of the match offer for the mtriQsic aUributes of , he ted of &nd 

application reqmrements tor each ot the network links from Qf ^ and 

installed on the 

a client to trie two servers. usef , s computer ^ i ntrinsic attributes of the game include 

In the prior discussions it has been assumed that once a 50 limiting values for communications attributes of links 

sufficient number of clients have joined a match offer for an between users' computers. In step 12, the MM receives this 

application that the application is launched with all of the request. A weU known intrinsic feature of the Internet 

clients that have successfully joined the match offer. The Protocol (IP) used by CL1 to send a request to the MM, is 

launch may be triggered by a moderator in a user created that all messages carry a return unique network address in 

match offer or may be triggered by the match maker when 55 me form of an Internet Protocol address (IPaddr.) exploiting 

enough clients have been matched to an automatic match which the MM can subsequently send a reply data message 

°^ er to the CL1, this eliminates any need for the CL1 to embed 

There is another important case of a persistent applica- an address within the request as might be needed on other 

tion. This is an application that allows clients to join and types of network or link. In step 13 the MM creates a record 

leave it during its operations. In this case, the game may be 60 to represent game offer (GOR1) which contains the 

launched by a single client or automatically by the match attributes from the request and the return unique network 

maker. In this case, the running application also embodies a address of CL1. Records, sets of records and techniques for 

match offer. If the application requires a server or servers, creating and maintaining them are well known in the com- 

they are chosen at the time that the application is launched. puter programming art. In step 14 the MM sends a reply 

The server is chosen based on its attributes and the required 65 back to CL1 notifying CL1 that the match is not yet 

attributes of the application. When a client requests to join complete (step 14% In step 15 CL1 waits for a request from 

the running application, the attributes of the client are MM. CL1 thus becomes the first member of a game match 
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yel to be completed. In step 16 the MM makes the contents 
of the game offer record available to other potential users. In 
step 17 MM waits for further requests from other clients. 

Referring to FIG. 2, in step 21, another instance of a client 
program (CL2) which is executing on a different user's 
computer from CL1 and also a different computer from MM, 
sends a request for a list of game offers to the MM. In step 
22 the MM receives this request. In step 23 the MM 
responds with information extracted from GOR1 that was 
created in step 13. In step 24 CL1 receives the response from 
MM which contains the game offer information from GOR1. 

Referring to FIG. 3, in step 31, CL2 sends to MM a 
request to be matched into the offer represented by GOR1. 
In step 32 the MM receives this request In step 33 the MM 
compares the attributes in the latest request sent by CL2 with 
those in GOR1 and if they do not match by whatever criteria 
the MM is programmed to use then CL2 is sent a message 
from MM that informs CL2 that it cannot join the offer 
represented by GOR1, at least not at this time (step 34). The 
use of programmed criteria to match requirements and sets 
of requirements is well known in the computer programming 
art. Assuming the attributes match, in step 35 the MM sends 
to CL2 a request to measure the communications attributes 
between CL1 and CL2. 

Referring to FIG. 4, in step 41, CL2 receives the latest 
described request from MM. In step 42 a determination is 
made by CL2 as to whether the request is a request to 
measure communications (comms.) attribute or is a rejec- 
tion. In step 43 CL2 measures the communications attributes 
of the data communications link between CL2 arid CL1. 
Methods of measuring communications attributes are well 
known in the arts. Not all communications attributes are 
mutually orthogonal, though the especially important ones 
of latency, bandwidth and packet loss rate arc indeed sub- 
stantially orthogonal. For example, CL2 could measure a 
data throughput rate attribute directly or CL2 could measure 
latency, bandwidth and packet loss rate separately and then 
calculate data throughput rate to a reasonable degree of 
accuracy (limited inter-alia by mensuration precision) from 
those three attributes by methods well known in the data 
communications arts. Another communications attribute is 
best case round trip time for a kilobyte sized message, this 
attribute is a function of latency, bandwidth and as a second 
order effect computer speed but is entirely independent of 
packet loss rate. Round trip times and methods of measuring 
them are also well known in the arts. In step 44 CL2 reports 
the results of measuring the attributes of the data commu- 
nications link between CL2 and CL1 back to MM. In step 45 
MM receives the message reporting the results of the 
comms. attribute measurement. 

Referring to FIG. 5, in step 51, the MM compares the 
communications attributes with the limiting values for com- 
munications attributes for the game recorded in GOR1 (or 
some predetermined default values for any limiting values 
for communications attributes absent from GOR1) and if 
(step 52) the communications attributes exceed any limiting 
values for communications attributes specified in GOR1 (or, 
in their absence predetermined defaults) according to pro- 
grammed criteria then in step 53 MM notifies CL2 that it is 
allowed to join the game offer and a further game offer 
record (GOR2) is created to record all the known attributes 
associated with CL2. Otherwise (step 54) CL2 is sent a 
message from MM that informs CL2 that it cannot join the 
offer represented by GOR1 (step 55). If not allowed to join, 
CL2 finishes. If allowed to join, CL2 waits for completion 
of a game match (step 56). 

Referring to FIG. 6, the MM must next determine whether 
or not the game match is complete. One vital criterion is 
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whether sufficient players are joined into the game offer 
(step 61). This embodiment uses the automatic match 
approach, so if a sufficient number of instances of client 
programs are joined then a time-out timer is started (step 62) 

5 for a predetermined interval such as 30 seconds during 
which time further clients may join the game provided the 
maximum allowed number is players is not reached (step 
63). Time-out timers are well known in the computer pro- 
gramming art. If a sufficient number of players is not yet 

10 joined then the time-out timer is not started yet and MM 
waits for more client (step 64). 

Until and unless the time-out timer expires further 
instances of client programs (CL3, CL4 etc) may join the 
game offer upon the same basis of negotiation as CL2 used, 

15 with the exception that the third and later clients (CLn) will 
be requested and required by the MM to measure and report 
back the communications attributes between the candidate 
instance of client program and all of the clients already 
joined (CL1 through CL(n-l)). 

20 Referring to FIG. 7, in step 71, when and if the time-out 
timer expires MM deems the game matched and sends 
messages to each of the clients (CL1 through CLn) to inform 
them of the successful completion of the game match. 
Otherwise MM takes no particular action in connection with 

25 the time-out timer (step 72). Upon receipt of the message 
informing them of the successful completion of the game 
match, each player's computer starts executing the game 
program instructions and each makes game data message 
exchanges between each user computer upon a Peer to Peer 
basis. At this point communication between the clients and 
the MM (which is a server) is no longer essential and 
gameplay proceeds. 

DESCRIPTION OF A FURTHER EMBODIMENT 
35 OF THE INVENTION 

By way of further illustration the present embodiment is 
an example subset of the general description of the present 
invention, the subset being directed to matchmaking for a 

4 o game that uses multiple clients to a single server with early 
server binding. The network that this particular embodiment 
uses is again the well known Internet. The above general 
description of the present invention is entirely enabling of 
the invention generally and of this embodiment in particular 

45 to a practitioner ordinarily skilled in the arts. 

A matchmaker server program is used, an executing 
instance of this program (abbreviated to MM) resides on a 
server computer. Each computer user (abbreviated to user in 
this embodiment) launches an instance of a client computer 

50 program on his computer which computer is then a client 
computer. 

Referring to FIG. 8, in step 101, an instance of a client 
program (CLIO) sends a request to the MM. The request 
asks the MM to create a game offer and the request includes 

55 attributes of the various game and match preferences chosen 
by the user together with intrinsic attributes of the requested 
type of game and attributes of the hardware and software 
installed on the user's computer. The intrinsic attributes of 
the game include limiting values for communications 

60 attributes of links between clients and game servers (GSs). 
In step 102, the MM receives this request. In step 103 the 
MM creates a game offer record (GOR10) which contains 
the attributes from the request and the return unique network 
address of CLIO. In step 104 MM matches the attributes 

65 recorded in GOR10 with the attributes (if any) that game 
servers (GSs) have, at their own initiative, previously 
reported to MM and which MM retained in records created 
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for this purpose. In the case that this matching of game 
server (GS) attributes to the attributes recorded in GOR10 
fails to identify a GS for which the attributes match GOR10 
adequately according to programmed criteria (step 105) then 
CLIO is sent a message from MM that informs CLIO that 
CLIO cannot join the offer represented by GOR10 (step 
106). 

Referring to FIG. 9, in step 111 the MM sends to CLIO a 
request to measure the communications attributes between 
CLIO and each of a shortlist of computers identified by the 
unique network addresses of all of the potentially compat- 
ible GSs identified by MM in step 104 above. 

Referring to FIG. 10, in step 121, CLIO receives one of 
the Latest described requests from MM. In step 122, a 
determination is made by CLIO as to whether the request is 
a request to measure communications attributes or is a 
rejection. If a rejection, then CLIO finishes. Otherwise, in 
step 123 CLIO measures the communications attributes of 
each of the data communications links between CLIO and 
the shortlisted GSs. In step 124 CLIO reports the results of 
measuring the various communications attributes back to 
MM. In step 125 the MM receives this report. 

Referring to FIG. 11, in step 131, the MM compares the 
communications attributes (for each path between CLIO and 
each of the GSs reported on) with the limiting values in 
GOR10 (or some predetermined default values for commu- 
nications attributes absent from GOR10) and if the commu- 
nications attributes exceed the limiting values according to 
programmed criteria specified in GOR10 or, in their absence 
predetermined defaults (step 132) then in step 133 CLIO is 
allowed to create a valid game offer by recording the unique 
network address of one of the qualifying servers in GOR10. 
This is termed early server binding. The server so selected 
(in step 133) is termed the early bound game server (EBGS). 
If no qualifying server is found then CLIO is sent a message 
from MM that informs CLIO that MM cannot create a game 
offer (step 135) and GOR10 is destroyed (step 136). Meth- 
ods for destroying records are well known in the arts. 

At CLIO, a determination is made as to whether MM has 
allowed CLIO to join game offer (step 137). If CLIO is 
allowed, then CLIO waits for completion of game match 
(step 138). Otherwise, if not allowed to join, CLIO finishes. 

When further clients attempt to join the game offer 
represented by GOR10, they are requested by the MM to 
measure the communications attributes only between them- 
selves and the EBGS. On reporting these communications 
attributes back to MM a determination is made as to whether 
those attributes exceed the limiting values according to 
programmed criteria established above so that the client may 
be allowed to join the game offer. 

This embodiment does not use the automatic match 
approach, so MM informs CLIO of the progress of the match 
as each client joins. When the user of CLIO is satisfied that 
a sufficient number of players have joined the match then the 
user of CLIO can stimulate CLIO to send a message com- 
manding MM to treat the match as completed. User stimu- 
lation of programs through means such as (for example) 
keyboards or computer mice is well known in the computer 
programming arts. The MM then sends each client a mes- 
sage informing the client of the completion of the match. 

Upon receipt of the message informing them of the 
successful completion of the game match, the each player's 
computer starts executing the game program instructions 
and makes game data message exchanges between the each 
user's computer and EBGS. At this point communication 
between the clients and the MM is no longer essential and 
gameplay proceeds. 
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DESCRIPTION OF A STILL FURTHER 
EMBODIMENT THE INVENTION 

By way of further illustration the present embodiment is 
an example still further subset of the general description of 

5 the invention, this subset being directed to matchmaking for 
a game that uses multiple clients to multiple servers with late 
server binding. The network that this particular embodiment 
uses is again the well known Internet. The general descrip- 
tion above is entirely enabling of the invention generally and 

io of this embodiment in particular to a practitioner ordinarily 
skilled in the arts. 

When a matchmaker server program is used, an executing 
instance of this program (MM) resides on a server computer. 
Each computer user (user) launches an instance of a client 

15 computer program on his computer which computer is then 
a client computer. 

An instance of a client program (CL20) sends a request to 
the MM. The request asks the MM to create a game offer and 
the request includes attributes of the various game and 

2Q match preferences chosen by the user together with intrinsic 
attributes of the requested type of game and attributes of the 
hardware and software installed on the user's computer. The 
intrinsic attributes of the game include limiting values for 
communications attributes of links between clients and 
game servers (GSs). Next the MM receives this request. The 

25 MM creates a game offer record (GOR20) which contains 
the attributes from the request and the return unique network 
address of CL20. Then MM matches the attributes recorded 
in GOR20 with the attributes (if any) that game servers 
(GSs) have, at their own initiative, previously reported to 

30 MM and which MM retained in records created for this 
purpose. In the case that this matching of game server (GS) 
attributes to the attributes recorded in GOR20 fails to 
identify a sufficient number of GSs (the number required is 
one of the attributes passed by CL20 to MM) for which the 

35 attributes match GOR20 adequately according to pro- 
grammed criteria then CL20 is sent a message from MM that 
informs CL20 that it cannot join the offer represented by 
GOR20. 

Next the MM sends to CL20 a request to measure the 

4Q communications attributes between CL20 and each of a 
shortlist of computers identified by the unique network 
addresses of all of the potentially compatible GSs previously 
identified by MM. 
Then CL20 receives the latest described request from 

45 MM. CL20 measures the communications attributes of each 
of the data communications links between CL20 and the 
shortlisted GSs. CL20 reports the results of measuring the 
various communications attributes back to MM. 
The MM compares the communications attributes (for 

so each path between CL20 and each of the GSs reported on) 
with the limiting values in GOR20 (or some predetermined 
default values for communications attributes absent from 
GOR20) and if the communications attributes exceed the 
limiting values according to programmed criteria specified 

55 in GOR20 (or, in their absence predetermined defaults) then 
MM creates for CL20 a valid game offer by recording all the 
unique network addresses of all of the qualifying servers in 
GOR20. 

The network addresses in this list of unique network 
60 addresses is necessarily a subset of the shortlist referred to 
above. 

The servers to be bound into the match are not yet selected 
because this embodiment uses late server binding. 

If an insufficient number of qualifying servers are found 
65 then CL20 is sent a message from MM that informs CL20 
that MM cannot create a game offer and GOR20 is 
destroyed. 
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When further clients attempt to join the game offer (iii) adding to said set of computer objects said second 

represented by GOR20, they are requested by the MM to client instance; and 

measure the communications attributes between themselves (e) adding to said set of computer objects a member of 

and all of the servers listed in GOR20 as qualifying. said second server subset based on attributes associated 

On reporting these communications attributes back to 5 with each member of said set of computer objects. 

MM a determination is made as to whether those attributes 2 * ^ method of claim 1, wherein one of said client 

exceed the limiting values for a sufficient number of servers attributes relates to capabilities of a computer system 

according to programmed criteria established above so that ex ™S a corresponding one of said client instances, 

the client may be allowed to join the game offer. If the client „ 3 . . ™ e ™*** of K claim h t whe f rei t n l 0I * of ^ chent 

is allowed to join the game offer then any servers for which 10 attnbutes re l ates to charactenstics of at least one user using 

. t . ~ t - . 4 r . a corresponding one of said client instances, 

the communications attributes of the further client fail to 4 j£ of daim x whcfem ^ ^ 

me ^ C o?« na ^ re TT ?° m f 6 • Qualifying servers indude communication attributcs of a network link associ . 

in GOR20. Thus the list of qualifying servers may become ated with „ system executing a corresponding one 

smaller and smaller as more clients join the game offer. q£ s^icj client instances 

This embodiment does not use the automatic match 15 5. The method of claim 4 wherein one of said commu- 

approach, so MM informs CL20 of the progress of the match nication attributes is bandwidth of said network link, 

as each client joins. When the user of CL20 is satisfied that 6. The method of claim 4 wherein one of said commu- 

a sufficient number of players have joined the match then the nication attributes is latency of said network link, 

user of CL20 can stimulate CL20 to send a message com- 7. The method of claim 4 wherein one of said commu- 

manding MM to treat the match as completed. At this stage 20 nication attributes is packet loss rate of said network link, 

the MM selects the GSs to be bound into the match. The 8. The method of claim 1 wherein one of said server 

servers most likely to result in good gameplay are chosen attributes relates to capabilities of a computer system 

according to programmed criteria and other factors includ- executing a corresponding one of said server instances, 

ing all the reported communications attributes. This is 9. The method of claim 1 wherein one of said server 

known as late server binding. The MM sends to each server 25 attributes relates to current load of a computer system 

a notification that the match is complete together with a list executing a corresponding one of said server instances, 

of the addresses of the servers selected. 10. The method of claim 1 further comprising the step of 

Upon receipt of the message informing them of the finding an instance of a server computer program from said 

successful completion of the game match, the each player's set of computer objects that minimizes average latency 

computer starts executing the game program instructions 30 between instances of server computer programs and 

and makes game data message exchanges between the each instances of client computer programs belonging to said set 

user's computer and each bound server. At this point com- of computer objects. 

munication between the clients and the MM is no longer 11. The method of claim 1, further comprising the step of: 

essential and gameplay proceeds. ^ repeating said augmenting step to add a predetermined 

It is to be understood that even though numerous embodi- number of client instances to said set of computer 

ments and advantages of the present invention have been set objects. 

forth in the foregoing description, the above disclosure is 12. The method of claim 11, further comprising the step 

illustrative only, and changes may be made in detail yet of: 

remain within the broad principles of the invention. 4Q repeating said augmenting step to add client instances to 

Therefore, the present invention is to be limited only by the said set of computer objects for a predetermined time 

appended claims. interval. 

What is claimed is: 13, The method of claim 1 wherein said client attributes 

1. A method for creating a set of computer objects, said set include multiplayer game attributes, 

of computer objects comprising a plurality of client 45 14. The method of claim 13 further comprising a step of 

instances of client computer programs together with a server providing a moderator for constructing said game attributes, 

instance of a server computer program selected from a set of 15. The method of claim 1, further comprising the step of: 

server instances, the method comprising the steps of: constructing a set of records, each record of said set of 

(a) receiving from a first client instance a first request to records comprising said server attributes. 

be joined into said set of computer objects, said first 50 16. The method of claim 15, wherein step (b) comprises 

request comprising first client attributes associated with the step of: 

said first client instance; selecting a record subset of said set of records in response 

(b) selecting a first server subset of said set of server to said first request based on said first client attributes, 
instances in response to said first request based on said 17. The method of claim 15, wherein step (ii) comprises 
first client attributes; 55 the step of: 

(c) creating said set of computer objects consisting of said removing from said record subset a further subset of said 
first client instance; set of records in response to said second request based 

(d) augmenting said set of computer objects with a second on said second client attributes. 

client instance of a client computer program, compris- 18. A system for creating a set of computer objects, said 

ing the steps of: 60 set of computer objects comprising a plurality of client 

(I) receiving from said second client instance a second instances of client computer programs together with a server 

request to be joined into said set of computer objects, instance of a server computer program selected from a set of 

said second request comprising second client server instances, the system comprising: 

attributes associated with said second client instance. (a) means for receiving from a first client instance a first 

(ii) removing from said first server subset a second 65 request to be joined into said set of computer objects, 

server subset in response to said second request said first request comprising first client attributes asso- 

based on said second client attributes, and ciated with said first client instance; 
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(b) means for selecting a first server subset of said set of 
server instances in response to said first request based 
on said first client attributes; 

(c) means for creating said set of computer objects 5 
consisting of said first client instance; 

(d) means for augmenting said set of computer objects 
with a second client instance of a client computer 
program, comprising: 

(i) means for receiving from said second client instance 
a second request to be joined into said set of com- 
puter objects, said second request comprising second 
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client attributes associated with said second client 
instance; 

(ii) means for removing from said first server subset a 
second server subset in response to said second 
request based on said second client attributes; and 

(iii) means for adding to said set of computer objects 
said second client instance; and 

(e) means for adding to said set of computer objects a 
member of said second server subset based on 
attributes associated with each member of said set of 
computer objects. 
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